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Abstract 


When experimenting with or extending protocols, it is often necessary 
to use some sort of protocol number or constant in order to actually 
test or experiment with the new function, even when testing in a 
closed environment. For example, to test a new DHCP option, one 
needs an option number to identify the new function. This document 
recommends that when writing IANA Considerations sections, authors 
should consider assigning a small range of numbers for 
experimentation purposes that implementers can use when testing 
protocol extensions or other new features. This document reserves 
some ranges of numbers for experimentation purposes in specific 
protocols where the need to support experimentation has been 
identified. 
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1. Introduction 


When experimenting with or extending protocols, it is often necessary 
to have a protocol number as part of the implementation [RFC2434]. 
For example, to develop a protocol that runs directly above IP, one 
needs an IP Protocol Number to place in the Protocol field of the IP 


header [RFC791]. In some cases, obtaining a new number is 
straightforward (e.g., a well-known TCP or UDP port) or not even 
necessary (e.g., TCP and UDP port numbers for testing purposes). In 
other cases, obtaining a number is more difficult. For example, the 


number of available and unassigned values in a name space may be 
small enough that there is concern that all available numbers will be 
used up if assigned carelessly. Even in cases where numbers are 
potentially plentiful, it may be undesirable to assign numbers unless 
the proposed usage has been adequately reviewed by the broader 
community. Consequently, some number spaces specify that IANA only 
make assignments in cases where there is strong community support for 
a proposed protocol. For example, values out of some name spaces are 
only assigned through an "IETF Standards Action" [RFC2434], which 
requires that the proposed use be in an IETF Standards Track RFC. 


In order to experiment with a new protocol, an experimental value may 
be needed that won’t collide with an existing or future usage. 


One approach is to allow IANA to make temporary assignments for such 
purposes. The idea is that a protocol value can be assigned to allow 
experimentation, but after the experiment ends, the number would be 
returned to IANA. There are several drawbacks to this approach, 
however. First, experience has shown that it can be difficult to 
reclaim numbers once assigned. For example, contact information 
becomes outdated and it can become difficult to find out what the 
status of an experiment actually is. Second, should deployment with 
the temporarily assigned number take place (e.g., it is included as 
part of a product), it becomes very difficult to determine whether or 
not reuse of that number would lead to adverse impact with regards to 
deployed devices. Finally, it can be difficult to determine when an 
experiment has ended and whether the number needs to be returned. 


An alternate approach, and the one recommended in this document, is 
to assign a range of numbers specifically earmarked for testing and 
experimentation purposes. Mutually consenting devices could use 
these numbers for whatever purposes they desire, but under the 
understanding that they are reserved for generic testing purposes, 
and other implementations may use the same numbers for different 
experimental uses. 
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Numbers in the experimentation range are similar to those called 
"Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not 
intended to be used in general deployments or be enabled by default 
in products or other general releases. In those cases where a 
product or release makes use of an experimental number, the end user 
must be required to explicitly enable the experimental feature and 
likewise have the ability to chose and assign which number from the 
experimental range will be used for a specific purpose (i.e., so the 
end user can ensure that use of a particular number doesn’t conflict 
with other on-going uses). Shipping a product with a specific value 
pre-enabled would be inappropriate and can lead to interoperability 
problems when the chosen value collides with a different usage, as it 
someday surely will. 


From the above, it follows that it would be inappropriate for a group 
of vendors, a consortia, or another Standards Development 
Organization to agree among themselves to use a particular value for 
a specific purpose and then agree to deploy devices using those 
values. By definition, experimental numbers are not guaranteed to be 
unique in any environment other than one where the local system 
administrator has chosen to use a particular number for a particular 
purpose and can ensure that a particular value is not already in use 
for some other purpose. 


Once an extension has been tested and shown to be useful, a permanent 
number could be obtained through the normal assignment procedures. 


Most implementations will not do anything special with numbers 
assigned for testing purposes. In particular, unless a packet or 
other Protocol Data Unit (PDU) is specifically directed at a device, 
that device will not even look at the field while processing the PDU. 
For example, IP routers do not need to examine or understand the 
Protocol Type field of IP datagrams in order to know how to correctly 
forward them. In those cases where a packet or PDU is directed at a 
device, and that device has not been configured to recognize the 
extension, the device will either ignore the PDU, discard it, or 
signal an error, depending on the protocol-specific rules that 
indicate how to process unknown options or features. In those cases 
where a protocol has different ways of handling unrecognized 
extensions (e.g., silently discard vs. signal an error), that 
protocol needs to reserve values for testing purposes from all the 
appropriate ranges. Only those implementations specifically enabled 
or configured to make use of an extension or feature that is being 
experimented with would process the data further. 
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1.1. Recommendation for Protocols 


To make it possible to experiment with protocol extensions safely, 
protocol documents should consider reserving a small set of protocol 
numbers for experimentation. Such reservations can be made through 
an explicit reservation in an IANA Considerations section. 


The exact number of values to reserve for experimentation will depend 
on the specific protocol and factors specific to that protocol. For 
example, in cases where the values of a field are subdivided into 
ranges that are treated differently (e.g., "silently ignore" vs. 
"return an error" if the value is not understood), one or more values 
from each sub-range may need to be reserved. 


For protocols that return error codes, it may also be appropriate to 
reserve a small number of experimental error values that can be used 
in conjunction with possible experimental uses. For example, an 
experimental message might result (even under normal conditions) in 
an error, with a special error code (or sub-code) indicating the type 
of error condition. 


In many, if not most cases, reserving a single value for experimental 
use will suffice. While it may be tempting to reserve more in order 
to make it easy to test many things at once, reserving many may also 
increase the temptation for someone using a particular value to 
assume that a specific experimental value can be used for a given 
purpose exclusively. Values reserved for experimental use are never 
to be made permanent; permanent assignments should be obtained 
through standard processes. As described above, experimental numbers 
are intended for experimentation and testing and are not intended for 
wide or general deployments. 


When protocols that use experimental numbers are included in 
products, the shipping versions of the products must disable 
recognition of protocol experimental numbers by default -- that is, 
the end user of the product must explicitly "turn on" the 
experimental protocol functionality. In most cases, a product 
implementation must require the end user to configure the value 
explicitly prior to enabling its usage. Should a product not have a 
user interface for such end user configuration, the product must 
require explicit re-programming (e.g., a special firmware download, 
or installation of a feature card) to configure the experimental 
number(s) of the protocol(s) implicitly. 


Narten Best Current Practice [Page 4] 


RFC 3692 Assigning Experimental and Testing Numbers January 2004 


2. IANA Considerations 
2.1. IP Protocol Field 


Assignment of new values for the IP Protocol field requires an IETF 
Standards Action per [RFC2780]. For the purposes of experimentation 
and testing, IANA has assigned the two values 253 and 254 for this 
purpose. These values have been allocated from the upper end of the 
available number space in order to make them easy to identify by 
having them stand out relative to the existing assignments that have 
been made. 


2.2. Existing Name Spaces 


Numerous name spaces exist for which no values have been reserved for 
experimentation or testing purpose. Experimental values for such 
protocols can of course be assigned through the normal process of 
publishing an RFC that documents the details of such an allocation. 
To simplify the process in those cases where the publication of a 
documentation just for the purpose of assigning an experimental 
allocation seems overkill, experimental values can be made through 
IESG Approval [RFC2434]. 


3. Security Considerations 
This document has no known security implications. 
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7. Full Copyright Statement 
Copyright (C) The Internet Society (2004). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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